Re: denial of service attack possible
der Mouse (mouse@Collatz.McRCIM.McGill.EDU)
Wed, 1 Nov 1995 13:41:11 -0500
>> [Denial of service possible by remote host putting multiple
>> connections to a port into the SYN_RCVD state, thereby precluding
>> further (legitimate) connection attempts.]
> This problem is partly in the way how the interface on top of TCP/IP
> has been defined. Had accept been defined in such a way that a
> connection request could be accepted and then rejected, there wuld
> not have been a problem.
It still could be done. On (old) Ultrix, DECnet sockets could be put
into such a state, and there's no reason the same thing couldn't've
been done for TCP (indeed, perhaps it was and I just didn't notice).
As I recall, the interface was you did some setsockopt on the listening
socket, then accept() returned a socket in (the analog of) SYN_RCVD and
you had to do something - an ioctl, a setsockopt, something like that -
to accept or reject the connection before much else would work. About
all you could do before doing the accept/reject was getsockname() and
getpeername(), I think - possibly some getsockopt/setsockopt calls
would work.
In TCP terms, accepting would release the kernel to generate the second
part of the three-way handshake; rejecting would probably produce an
RST, or maybe synthesize an ICMP Port Unreachable, though I don't like
the latter option because it amounts to telling a lie. (It also could
cause trouble if the same machine sends you multiple SYN segments, some
of which you want to accept and some reject.)
> This backlog parameter also severely limits the number of
> connections/second an http server can accept.
Well, not quite: the listen backlog limit collaborates with network
round-trip delays and scheduling delays to produce the effective limit.
der Mouse
mouse@collatz.mcrcim.mcgill.edu